Allow with custom cabal path #25
Conversation
Allows usage with custom cabal path. Additionally, adds general --cabal-options argument, for passing through arbitrary cabal options. The latter subsumes the --jobs and --cabal-verbosity args, hence they are removed. The previous behavior can be achieved with e.g. clc-stackage --cabal-options='--jobs=semaphore --verbose=1'
|
The second commit is technically unrelated to the linked issue, though I think it is useful to include here.
|
When the default stackage json endpoint fails, fallback to trying the <snapshot>/cabal.config endpoint. The latter seems more reliable. This also allows us to easily add a --snapshot-path CLI arg, giving users the ability to pass in a snapshot file manually.
|
This looks very useful. I will try to use it today and will report back. Thanks a lot. |
Cabal constraints, like those returned from stackage's cabal.config endpoint, can specify packages in a number of ways, including e.g. 'mtl installed'. Previously we were ignoring such constraints. We now parse these too.
Using megaparsec was probably overkill, as the constraint parsing is simple enough that we can do it with text without too much trouble.
Displayed package names (stdout, log directory names) now use a hyphen e.g. aeson-1.2.3, rather than reusing the default delimiter == e.g. aeson ==1.2.3.
|
Assuming this solves the stated problem, I am satisfied with the PR. I do have one more commit that I'd like to merge at some point -- it consolidates the multiple libraries into a single one (imo an improvement for several reasons) -- but I'll refrain from pushing it up until there is consensus on what is up, since the filepath renaming probably ruins the diff. |
|
I tested this patch, but couldn't get the store-dir argument to work. I think the issue is that |
|
Ah, you are exactly right. I just added a new > clc-stackage --cabal-path=path/to/my-own-cabal --cabal-global-options='--store-dir=path/to/my_store_dir' |
|
Very good, thank you. |
|
Amazing, thanks @tbidne. |
Hopefully resolves #24.
@sheaf does this work for you? I believe your previous example:
> my-own-cabal --store-dir=my_store_dir build clc-stackage --keep-goingwould now be (
--keep-goingis on by default):Unfortunately testing this is a bit hard at the moment, as stackage's json endpoint is currently unreliable. I just ran it and made sure the cabal arguments looked reasonable.Edit: I have realized it's pretty easy to make this more robust wrt stackage flakiness, so I'll try to add that to this PR as well.